現代的軟體專案管理有二大流派，瀑布式開發（Waterfall）與敏捷開發（Agile），各有不同的優缺點，以及各自的使用時機，這篇我們來聊聊瀑布式開發的前世今生。

瀑布式開發

1970 年代，Winston W. Royce 在 IEEE WestCom 軟體工程學會中發表的論文中，首次提出著名的傳統瀑布式方法。當時的命名雖沒提到「瀑布」二字，但他明確描述了一種線性的開發流程，每一個階段都必須等待上一個階段完成後才能開始。有趣的是，當時他其實想描述的是軟體開發不建議這麼做，於是接著又描述了一種類似現今敏捷的迭代開發方式的工作流程。但不知為何，在當時反而是瀑布式模型受到大家的注意而廣為人知。

後來，美國國防部在 1985 年開始規定，政府之下所有專案的標準，都要遵守瀑布式的原則，從此之後，瀑布式開發方式成為所有企業開發軟體時的模型。

瀑布式開發大致上可分為五個階段：

1. 需求訪談及範籌定義

   需求端提出需求，開發端對其做完整的需求訪談，產生出相關文件，並且讓設計師進行介面設計。

2. 系統分析與設計

   架構師／系統分析師根據上個階段產出的規劃文件，進行細部規劃，決定要使用的技術、環境，以及程式的架構設計等。

3. 功能實作及單元測試

   工程師根據系統分析與設計的定義，進行程式碼撰寫，邊寫邊測試自己所寫的程式是否能夠正常運作。

4. 整合測試及驗收

   針對前一階段各個程式設計師撰寫的程式碼，整合並進行整體測試。測試完後安排時間讓需求端、利害關系人驗收。

5. 部署及維運

   Debug 及驗收都沒問題後，最後將整套系統部署到最終環境，維運整個系統，確保正常運作。

瀑布式開發的優缺點

瀑布式的優點是清楚、簡單明瞭，要完成的項目天生就相當適合以 WBS （Work Breakdown Structure）進行分解各個擊破，搭配甘特圖明確掌握每個細部項目所需花費的人天（Ｍan-Day）是多少、關鍵路徑（Critical Path）又是哪一條，簡言之，能夠有效規劃時程，且工作項目也能結構化地向上級清楚匯報；另外，在甲方乙方的關係中，此開發方式的規格闡述，對於雙方在合約中的驗收條件及範籌都很容易訂定且易於理解。

那麼問題來了，這麼好棒棒的方法，為何現今的趨勢會發展出另一種方法－敏捷開發呢？重新審視一下，能夠發現瀑布開發存在一些早已不合現今時宜的缺點。

首先，現今商業環境相當不穩定，勢頭持續在變化，不能再像上一代做產品的方式，一股腦拼命地開發出產品，認為這樣就會有人買單。如今，產品負責人需經常性的重新審視方向是否需要調整，快速適應新的商業變化。瀑布式的缺點就是交付價值的時間相當長，須要等到所有的流程都做完，直到走到最後一階段，才能夠向客戶交付價值。

其次，瀑布是一個從上而下的線性流程，中間若有問題，得回溯到上源做修正，再往下走。所以這種方式非常講求 BDUF （Big Design Up Front）的完美性，尤其是分析與設計階段不能有錯（犯錯的成本實在太高，得要回溯到上個階段重新進行，才能再往下走），但這已經不太符合現今時宜，一來軟體開發過程中處處充滿驚喜，怎麼可能不犯錯？二來現今商業環境變化劇烈，需求也會隨之變更，想在每個階段做到「完美化」的設計與規劃，不太實際。

用個製造汽車形象的比喻，有點像是下圖這樣，注意圖中的每個階段，其實都存在著風險，最終交付時，更是風險的疊加。

瀑布流開發流程適合用在需求已非常明確，範籌不太會更動，或是規範嚴謹的系統上。一般而言，它需要橫跨多部門協作，溝通成本高、偏好頂層設計、也需要小心每個階段盡量不犯錯，正因這些限制，採用瀑布式的專案開發，難以做到快速反應，並且缺乏彈性。